1.1 Prior Art
The rapid development of the Internet has resulted in a scarcity of IP addresses. The solution most commonly used to mitigate this problem lies in the use of NAT devices. Classically, a home router such as an STB (Set Top Box) to which the computer network of a dwelling is connected therefore integrates a NAT device.
The communications means situated behind the router within the local (home) network are in private addressing mode and do not have a priori knowledge of the device behind which they are located, especially the public address used on the Internet for their communications and the precise type of NAT used.
However, in certain exchanges, especially point-to-point exchanges between two machines, at least one of which is situated behind a NAT device, within a local network, the machine of the local area network (the <<client>> machine) may need to have knowledge of this information on connection with the exterior. Such information may be: the address and the public ports assigned by the NAT, the type of NAT (symmetrical, restricted port, etc), for example.
According to the prior art, a STUN (the name of the standardized IETF RFC 3489 protocol: “Simple Traversal of UDP over NATs”) can be used to send the client of the local network the public address at which it is seen and the type of NAT device behind which it is connected, by setting up a secured packet transmission session. A session of this kind relies on session data including two IP addresses associated with the STUN server.
The STUN algorithm applied by the client comprises several tests to determine the type of NAT device. In one of these tests, the STUN client of the local network will ask the STUN server to reply to it from an IP address different from the one from which it has responded hitherto. This test is aimed at enabling the client, through interpretation of the response or non-response to this request, to know whether the NAT device to which it is connected is blocking a packet that comes from an IP address with which it has never communicated.
In the current state of the prior art techniques, a STUN server, in order to be capable of responding to this kind of request, must possess two different IP addresses. Thus, when a client CSTUN wishes to address a server STUNA, it starts by first of all setting up a TLS/TCP connection (encrypted connection) and sends a request SHARED-SECRET-REQUEST on this connection for exchanging a shared secret. The server STUNA responds by a SHARED-SECRET-RESPONSE message with a user name and a password as attributes.
All the following requests, sent according to the UDP (“User Datagram Protocol”) comprise a field recalling the user name and another message integrity field which constitutes a signature of the message by means of the preliminarily exchanged password. Such an approach ensures that all the following requests have truly been exchanged with the same server (the communications session is therefore secured).
Upon reception of any STUN request of a <<Binding-Request>> type, a STUN server must announce its other address (CHANGED-ADDRESS attribute) from which it is capable of responding if the client CSTUN asks it to respond from a different address (cf. §11.2.3 of the RFC 3489 STUN standard).
2. Drawbacks of the Prior Art
One problem related to this standard arises in the context of deployments on P2P (peer-to-peer) type distributed networks. In such an architecture, it is sought to reduce the number of functions hosted in centralized servers to the utmost extent. On this basis, the hosting of these functions has to be integrated into P2P network clients. Now such clients generally have only one public IP address.
According to the prior-art techniques and the specifications of the STUN protocol, it is extremely difficult in the context of P2P networks to deploy STUN servers as described by the standard. Thus, the functions of the STUN servers are hosted within a central server.
Indeed, the great scarcity of IP addresses due to an extremely rapid growth of requests for assignment linked to a high growth in the number of servers on the Internet is giving rise to problems. Thus, it is becoming hard to envisage the possibility of equipping all home STUN servers with two IP addresses used solely to respond to calls from clients wishing to obtain peer-to-peer connection.
A corollary drawback of this prior-art technique is the deterioration of the scalability of peer-to-peer architectures owing to restrictions related to the STUN protocol.